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PROCEDE D'ACCES A UN SERVICE A TRAVERS UN RESEAU D'ACCES 

MULTIVOIES 



La presente invention concerne un proc6d6 d'accds, & travers un 
reseau d'acces multivoies, d'un terminal a un service mis a disposition sur un 
reseau de communication par un fournisseur de services. 

L'invention trouve une application particuli&rement avantageuse dans le 
domaine de la fourniture de services, notamment sur le reseau Internet, 
lorsque I'acces au service est realise & travers un reseau d'acces multicanal 
ou a travers une pluralite d'interfaces du terminal. On dit alors que I'acces au 
service se fait au travers d'un reseau d'acces « multivoies ». 

Bien que invention s'applique a tout type de r§seau de communication, 
on se placera dans la suite de ce memoire dans le cas du reseau Internet. Le 
service auquel le terminal cherche a acc§der sera note service IP (Internet 
Protocol). 

Le cadre general de ['invention est done celui ou un fournisseur de 
services souhaite voir transporter un service IP comme, par exemple, une 
vid6o en « stream » ou en telechargement, jusqu'a des terminaux clients 
connectes £ un reseau d'acces IP multicanal ou a travers une pluralite 
d'interfaces du terminal vers des reseaux d'acces IP. On appellera « voie » 
indifferemment un canal d'un reseau d'acces multicanal ou une interface du 
terminal. 

Un reseau d'acces est appele, par la suite, reseau d'acces multicanal 
s'il contient soit un support physique avec piusieurs canaux logiques, soit 
plusieurs supports physiques. On appellera alors « canal » indifferemment un 
ensemble support physique/canal logique ou un des supports physiques. 

Parmi les reseaux d'accds multicanal connus, on peut citer le reseau 
DAB (Digital Audio Broadcasting) et le reseau DVB (Digital Video 
Broadcasting). 
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D'une maniere generate, le terminal-client decouvre le service IP 
aupres d'une fonction appelee « Offre de service ». Au prealable, les 
informations transmises par !e fournisseur renseignent, aujourd'hui, un module 
de mediation, et done !e terminal, sur la connexion IP, & savoir l'(es) 
adresse(s) IP associee(s) a un port TCP/UDP (Transfer Control Protocol/User 
Datagram Protocol)) et les caracteristiques de Papplication a utiliser pour 
traiter un service donne, par exemple les caracteristiques de decodage pour 
un service video et les caracteristiques de rapplication de telechargement. 

II faut noter que plusieurs connexions correspondant a plusieurs flux IP 
peuvent §tre necessaires pour «consommer» un service IP donne, par 
exemple une connexion pour la video, une autre pour I'audio dans le cas d'un 
service IP audio/video. Par la suite, on f era I'hypothese que le service IP ne 
contient qu'un flux IP. ^invention s'etend n6anmoins par analogie au cas de 
plusieurs flux IP associes au service. 

S'agissant d'un acces a un service IP a travers un reseau multicanal, la 
description du service est habituellement faite par le fournisseur de services 
dans un fichier du type SDP (Service Description Protocol recommande par 
TIETF (Internet Engineering Task Force)), mais n'inclut aucune information sur 
les caracteristiques du reseau d^cces multicanal a utiliser, notamment le 
canal (support physique/canal logique) a utiliser. 

Traditionnellement, on utilise les m6canismes de configuration de 
r6seau du terminal (tables de routage, configuration r6seau des interfaces) 
afin de trouver le chemin de communication vers un service IP donne. 
Cependant, dans le cas par exemple ou il n'y a pas de configuration reseau 
associee prealablement aux canaux logiques, comme e'est effectivement le 
cas des reseaux de diffusion DVB, DAB, ces techniques traditionnelles sont 
inoperantes. 

Neanmoins, pour eviter a I'utilisateur d'avoir ^ rechercher 
systernatiquement le chemin de communication adequat vers le service IP 
parmi Tensemble des canaux existants, les parametres de connexion au 
reseau d'acces doivent etre connus du terminal afin de s'accorder tout de suite 
sur le bon canal (couple support physique/canal logique). 
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Par exemple, le fournisseur du service IP envoie son contenu au travers 
d'un reseau d'acces a une adresse IP notee @ associee a un port P. En 
parallele, le fournisseur du service IP presente au terminal, lors de la 
decouverte du service IP, la description de ce service en lui fournissant, par 
exemple pour un service multicast, les informations @ et P et la nature de 
I'application App a utiliser. 

Dans le cas d'un reseau d'acces multicanal de type DAB, les 
equipements du reseau d'acces (passerelles ^encapsulation IP dans des 
multiplex DAB) encapsulent le flux IP (@, P) dans un ensemble multiplex E, 
dans un sous-canal S de ce multiplex, et dans un paquet Pa de ce sous-canal. 

Le terminal ne peut se connecter au service IP (@, P) qu'a condition 
que sa configuration au reseau d'acces DAB corresponde aux parametres (E, 
S, Pa) choisis par I'operateur du reseau d'acces. 

Dans le cas d'un reseau d'acces multicanal DAB, la signalisation 
envoyee aujourd'hui par les equipements du reseau d'acces utilise I'identifiant 
(Service Id, Service component Ids), qu'on notera par la suite (Sid, SCIds), 
caracterisant de facon unique une composante de service dans un reseau 
DAB. sachant qu'un flux IP donne est transports dans une composante unique 
de service. 

Cet identifiant reste invariant quelles que soient les operations de 
multiplexage/remultiplexage. La signalisation du reseau d'acces DAB relie le 
couple (Sid, SCIds) aux supports physiques et aux canaux logiques utilises 
dans le systeme de transport DAB (ensemble E, sous-canal S, paquet Pa). 
Ainsi. a condition de connaTtre le couple (Sid. SCIds) associe a un service IP 
donne. le terminal peut connaTtre. via la signalisation recue du reseau d'acces. 
le canal (support physique/canal logique) de connexion au service IP desire. 

Aujourd'hui, I'utilisateur doit selectionner manuellement de maniere 
empirique, ou de maniere statique par contrat, les parametres d'acces au 
reseau DAB, par exemple en selectionnant le nom du service DAB et le nom 

du "service component". 

Le terminal est alors accorde sur le bon support physique et le bon 
canal logique. I'extraction des donnees IP peut done se faire en accord avec la 
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description de service, concernant les informations de niveau applicatif et la 
connexion IP, foumie par le fournisseur de services IP. 

Dans le cas d'un r6seau multicanal DVB, une nouvelle table, dite table 
INT, a 6te definie dans la specification ETSI EN 301 192 vl.3.1 (2003-05). 
Cette table est mise a jour dynamiquement par les equipements du r6seau 
DVB (passerelles decapsulation IP dans DVB, multiplexeur/remultiplexeur) 
et donne un lien entre les services IP encapsules (definis par exemple par les 
adresses IP destination et source) et le canal (support physique/canal logique) 
qui les transporte. 

La decouverte par le terminal du service IP est faite ind6pendamment. 
Neanmoins, une partie des informations de d6couverte d'un service IP, 
notamment les caracteristiques de la connexion IP, comme les adresse IP 
destination et source, doivent etre renseignees dans la signalisation DVB afin 
d'effectuer un lien avec le canal d'acces. 

Toutefois, ces solutions connues propos6es pour acceder a un service 
IP a travers un reseau d'acces multicanal pr6sentent chacun un certain 

nombre d'inconv6nients. 

Concernant le reseau DAB, on constate qu'aujourd'hui le client doit, 
dans deux operations separees et independantes, decouvrir, d'un cot6, les 
services IP, et configurer Tinterface de connexion au reseau d'acces, de 
Tautre. 

Uutilisation du r6seau d'acces DAB pour transporter des services IP est 
recente et reste souvent experimental. Un processus ou le client apprend de 
fagon "statique" (au travers d'un contrat par exemple) sur quel canal DAB 
defini par le couple (Sid, SCIds) sont vehicul6s les flux IP peut convenir. 

Dans un environnement plus dynamique, Taffectation d'un service IP a 
un couple (Sid, SCIds) peut ne pas etre connue en temps reel par le client. En 
outre, Pergonomie d'une configuration manuelle peut rapidement etre 
inconfortable au cas ou le passage d'un service IP donne a un autre necessite 
quasiment systematiquement une reconfiguration de interface de connexion 

au reseau d'acces. 

Concernant le reseau. DVB, la table INT de la signalisation DVB indique 
dynamiquement la localisation du service IP donne, mais le terminal doit 
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analyser de fagon croisee deux types de signalisation, a savoir les 
informations de decouverte de services et les informations de la table INT. 
L'identifiant caract6risant le service IP doit etre duplique dans les deux 
signalisations, entraTnant done une surcharge d'informations alourdissant de 
fagon notable la signalisation DVB et augmentant aussi le temps d'analyse du 
terminal. 

Dans le cas d'un terminal ayant plusieurs interfaces de reseaux 
d'acces, une difficult^ peut apparaTtre lors du choix de I'interface £ laquelle le 
terminal du client devra se connecter pour recevoir un service IP multicast 
donne, a savoir le cas ou le service n'est accessible qu'au travers d'un r6seau 
d'acces non pr6visible a priori par le terminal. 

Aussi, le probleme technique a resoudre par I'objet de la pr6sente 
invention est de proposer un precede d'acces, a travers un reseau d'acces 
multivoies, d'un terminal a un service mis a disposition sur un reseau de 
communication par un fournisseur de services, qui permettrait, dans les cas 
. ou I'acces a un service IP ne peut etre connue a I'avance par le terminal, par 
exemple si elle depend de la mise en ceuvre non predictible du service IP 
dans un reseau d'acces multivoie, de fournir au terminal en meme temps que 
la decouverte du service IP (exemple dans un fichier SDP), les informations 
qui lui permettront de s'accorder automatiquement, et sans creation de tables 
chez I'operateur d'acces, sur le bon canal (support physique/canal logique) du 
reseau d'acces ou la bonne interface & un reseau d'acces. Ces informations 
seront a jour au moment de la decouverte de services. Si en outre on utilise 
un identifiant invariant dans le temps et dans l'espace, les informations 
transmises au moment de la premiere decouverte du service resteront a jour 

pendant toute la duree du service. 

La solution au probleme technique pose consiste, selon la presente 
invention, en ce que ledit procede d'acces comprend les etapes consistant : 
- pour le fournisseur de services, a fournir a un module de mediation des 
informations concernant au moins des donnees relatives a I'adresse dudit 
service dans le reseau de communication, 
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- pour le module de mediation, a determiner au moins un identifiant de voie a 
utiliser par le terminal pour acceder audit service, et a associer ledit identifiant 
de voie auxdites informations foumies par le fournisseur de services, 

- pour le terminal, a recevoir du module de mediation, lors de la d6couverte du 
service, ledit identifiant de voie assocte auxdites informations. 

Comme on le verra en detail plus loin, I'acces du terminal au service IP 
peut se resumer de la maniere suivante dans le cas, par exemple, de services 
IP multicast sur un r6seau d'acces multicanal DAB. 

Dans une premiere phase, le fournisseur de services IP qui souhaite 
offrir un service aupres d'un operateur de reseau d'acces fournit a un module 
de mediation la description de son service qui comporte les elements que Ton 
trouve dans un fichier SDP standard, a savoir : 

- des informations de niveau applicatif, comme nom et description litterale du 
service, date de diffusion du service, application necessaire pour decoder le 
service, type de codecs,... 

- des informations de niveau reseau, comme adresse IP multicast et port UDP 
n6cessaire pour communiquer avec le service IP multicast. 

Si les informations de description de services ci-dessus ne suffisent pas 
a expliciter la demande de ressources, des informations complementaires sont 
ajoutees, comme par exemple I'identifiant du service auquel est associ6 le 
service IP, tel que le service France Inter sur DAB. 

Dans une deuxieme phase, le module de mediation, grace a la 
description du service foumie par le fournisseur de service IP, envoie des 
commandes vers I'operateur de reseau d'acces qui active les ressources de 
transport IP qui vont permettre de transporter le service IP dans un canal 
donne. Un exemple d'activation des ressources de transport IP est la 
commande des passerelles d'encapsulation de donn6es IP dans le reseau 
d'acces en utilisant les elements caracterisant le service IP (adresse IP, port) 
et le canal de transport du service IP. Conformement a I'invention, la fonction 
de controle du r6seau d'acces retourne au module de mediation le canal qui 
transportera le service IP. Le module de mediation associe alors I'information 
de canal aux autres informations recues du fournisseur de service. 
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Dans une troisieme phase, le client decouvre le service au moyen de 
son terminal. L'information qu'il recoit par SDP par exemple contient au 
minimum: 

- les informations de niveau applicatif (codecs,.. .). 

- les informations de niveau reseau (adresse IP multicast, port), 

- et, conformement a I'invention, le lien avec le canal d'acces, par exemple 
I'identifiant Sid de service DAB et I'identifiant SCIds de la composante de 
service. 

Enfin, dans une quatrieme phase, le terminal se connecte au service IP 
a I'aide de ces parametres. Dans le cas d'un reseau multicanal, le terminal 
s'accorde sur le canal correspondant auxdits parametres. Dans le cas d'une 
pluralite d'interfaces, le terminal peut configurer de facon dynamique les 
parametres reseau du terminal et meme fournir aux applications I'interface 
reseau d'acces au service correspondant auxdits parametres. 

La description qui va suivre en regard des dessins annexes, donnes a 
titre d'exemples non limitatifs, fera bien comprendre en quoi consiste 
I'invention et comment elle peut etre r§alis§e. 

La figure 1 est un schema d'un systeme de communication entre le 
serveur d'un fournisseur de services et un terminal, destine a la mise en 
ceuvre du precede d'acces conforme a I'invention. 

La figure 2 est un schema sur lequel sont representees les etapes du 
precede d'acces conforme a I'invention dans le cas du reseau d'acces DAB. 

La figure 3 est un schema sur lequel sont representees les etapes du 
precede d'acces conforme a I'invention dans le cas d'un acces du terminal au 
service IP a travers une pluralite d'interfaces. 

Le systeme de communication de la figure 1 est destine a permettre 
I'acces d'un terminal T, tel qu'un ordinateur personnel d'un client, a un service 
d'un fournisseur de services distribue par un serveur S de contenus IP a 
travers un reseau 2 de communication, par exemple le reseau Internet. 

Pour acceder au service IP souhaite, le terminal T utilise un reseau 1 
d'acces multivoies qui, dans la suite de la description, sera le reseau d'acces 
multicanal DAB. 
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En liaison avec le r6seau 1, un systeme 3 abrite les interfaces de 
transfert vers le r§seau d'accds muiticanal (passerelles decapsulation de 
donn§es IP sur support DAB par exemple) qui aiguilleront les flux de donnees 
IP sur un canal d6fini par un ensemble support physique/canal logique du 
reseau 1 d'acces. v 

Eventuellement, le systeme 3 comporte des equipements de 
signalisation propres au r6seau 1 d'acces. Cette signalisation optionnelle 
permet de donner les caracteristiques finales de localisation cTun service IP 
que le r6seau 1 d'acces est parfois le seul a connaTtre. Dans I'exemple d'un 
service IP multicast transports sur un r6seau d*acc§s DAB, le recours a la 
signalisation du reseau d'acces DAB est obligatoire : c'est elle qui fournira le 
lien entre un couple (Sid, SCIds) et le canal au sein des multiplex DAB . 

Le syst6me 4 est un module de mediation qui abrite les fonctions de 
signalisation auxquelles fait appel le fournisseur S de services IP. Le module 4 
de m6diation peut appartenir au fournisseur de services lui-rn§me ou une 
autre une entite tierce a laquelle il fait appel. 

Le systeme 5 abrite les fonctions de controle des ressources propres 

au reseau 1 d'accSs muiticanal. 

Le reseau 1 b est facultatif . II permet au terminal T de dialoguer avec le 
module 4 de mediation par un autre reseau d'acces que le reseau 1 d'acces 
muiticanal. Ce sera le cas par exemple lorsque le terminal T veut envoyer des 
messages vers le systeme 4 alors que le r6seau 1 d'acces muiticanal ne 
permet que la transmission des messages de interface 3 vers le terminal T. 
Cette situation *se presente effectivement pour le n&seau DAB qui est 
unidirectionnel dans le sens emetteur vers recepteur. 

Les echanges de donnees et d'informations au sein du systeme de 
communication de la figure 1 s'effectuent de la maniere suivante.. 

Les donn6es echang6es du serveur S de contenus IP vers le terminal T 
transitent par le r6seau 2, puis Tinterface 3 et le reseau 1 d'accfes muiticanal. 

Le module 4 de mediation dialogue avec I e systeme 5 au travers du 
reseau 2. 

Le systeme 5 dialogue avec Tinterface 3 au travers du r6seau 2. 
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Le module 4 de mediation dialogue avec le terminal T au travers du 
r6seau 2 puis du reseau 1 ou du reseau 1b. 

Les etapes du procede d'acces conforme a Tinvention vont maintenant 
etre d6crites en detail en regard de la figure 2 relativement a un acces 
multicanal. 

1.a - Le fournisseur de services IP souhaite distribuer son service IP 
jusqu'a des terminaux clients, tel que le terminal T. Pour cela, il fait appel au 
module 4 de mediation, lequel peut etre sous-trait6 chez un tiers ou integre au 
serveur du fournisseur de services. Pour cela, le fournisseur S fournit a la 
fonction "Description de services" du module 4 les Elements de description de 
son service IP. 

Les etements fournis sont ceux que Ton trouve dans un flchier de 
description SDP (RFC 327 de FIETF) standard: a savoir: 

- des informations de niveau applicatif: nom et description litterale du service, 
date de diffusion du service, application necessaire pour decoder le service, 
type de codecs, etc, 

- des donnees de niveau reseau: adresse IP multicast et port UDP necessaire 
pour communiquer avec le service IP multicast. 

Si les informations de description de service ne suffisent pas & expliciter 
la demande de ressources, des informations complementaires sont ajoutees 
afin de completer le cas ech6ant I'appel a la demande de ressources 
effectuee lors de I'etape 1.b. Pour un service IP multicast sur DAB, ces 
informations complementaires sont, par exemple, le fait que le fournisseur de 
services souhaite diffuser son service sur une technologie DAB, le label du 
service radio auquel le service IP est rattache, la bande passante necessaire, 
la zone geographique ou le service sera opere, Toperateur de r6seau d'acces 
souhaite, etc. 

La fonction "Description de services" du module 4 de mediation stocke 
la description du service dans la base de donnees du module. 

1.b - La fonction «Demande de ressources» du module 4 de mediation 
est inform6e de Texistence d'un nouveau service IP pour lequel une demande 
de ressources est n6cessaire. La fonction «Demande de ressources» doit 
alors s6lectionner Top6rateur de reseau 1 d'acces. 
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Elle doit ensuite selectionner les informations qui caracteriseront aupres 
de Top§rateur du r6seau 1 d'acces la demande de ressources: par exemple 
les adresses IP et port du flux IP, et un certain nombre d'elements 
complementaires comme la bande passante desiree. 

2.a - La fonction "Activation des ressources" du systeme 5 regoit la 
demande de ressources. 

2.b - Au cas ou la demande est recevable, par exemple si la bande 
passante necessaire est disponible dans les ressources d'acces DAB, le 
systeme 5 envoie des ordres vers les equipements 3 de transfert afin que le 
service IP puisse etre transports sur le reseau 1 d'acces dans un canal donne 
(physique donne et un canal logique donne). Les informations transmises aux 
equipements 3 sont celles qui caracterisent le service IP (exemple (adresse 
IP, port)) ainsi qu'une designation du support physique/canal logique sur 
lequel devra etre vehicule le service IP. 

2. c - En reponse & la demande de ressources effectuee en 2.a, la 
fonction «Cdntr6Ie de ressources» du systeme 5 fournit I'identifiant permettant 
de determiner le canal qui sera utilise pour transporter le service IP sur le 
r6seau 1 d'acc&s multicanal. Par la suite, ce champ sera appele « identifiant 
de localisation du canal dans le reseau d'acces ». En DAB, cet identifiant 
repr6sente le couple (Sid, SCIds). 

3. a - La fonction "Demande de ressources" du module 4 de mediation 
met a jour la base de donnees du module en associant aux informations de 
description du service IP le champ « identifiant de localisation du canal dans le 
reseau d'acces ». 

3.b - La fonction "Offre de sen/ices" du module 4 est informee qu'elle 
doit cr6er un fichier de decouverte de services associe au service IP. Si la 
decouverte de services est faite au travers d'un fichier SDP, ce fichier 
contiendra les champs presents dans la base de donnees et regus par la 
fonction decouverte de services (champs d'un fichier SDP standard) et le 
nouveau champ « identifiant de localisation du canal dans le reseau 
d'acces ». Ce champ est place dans une description SDP de niveau media, au 
cas ou il y aurait plusieurs m6dias et done plusieurs flux IP associes au 
service IP. 
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4.a - Le terminal client T par sa fonction "D6couverte de services" * 
decouvre le service IP : 

- soit en envoyant une requ§te aupres de la fonction "Offre de services" du 
module 4, en tel6chargeant par exemple le fichier SDP sur un serveur WEB 
mis a jour par la fonction "Offre de services" du module 4, 

- soit par l'envoi des informations par la fonction "Offre de services" vers le 
terminal T au travers d'un protocole comme SAP/SDP (RFC 2974). 

4.b - La fonction "Invocation de service", qui peut etre sollicitee au 
moment ou I'utilisateur selectionne sur I'interface graphique du terminal T le 
service IP (die sur un icone par exemple), traite le fichier de decouverte de 
services (fichier SDP par exemple), et done le champ « identifiant de 
localisation du canal dans le reseau d'acces ». 

4.c - La fonction "Invocation de service" du terminal T lance I'application 
en lui fournissant les parametres presents dans le fichier de decouverte de 
services et qui lui sont necessaires. Grace aux parametres de communication 
IP (classiquement adresse(s) IP et port), I'application ouvre la connexion IP. 

4.d - La fonction "Invocation de service" communique par une interface 
de type API avec la carte du terminal de connexion au reseau 1 d'acces et lui 
fournit les parametres presents dans le champ « identifiant de localisation du 
canal dans le reseau d'acces ». 

Au niveau de la carte de connexion au reseau 1 d'acces, le recours a 
une analyse de la signalisation est optionnelle, mais obligatoire dans le cas 
d'un reseau DAB. 

Au moment ou la carte du terminal T est accordee sur le bon canal 
(support physique/canal logique), les donnees IP issues du serveur S de 
services au travers des equipements du reseau 1 d'acces physique sont 
recues par la carte de reception du terminal T et traitees par I'application 
desiree (lecteur de video par exemple). 

Les etapes du precede d'acces conforme a I'invention vont maintenant 
etre decrites en detail en regard de la figure 3 relativement a un acces 
multiinterfaces. 

On decrit ici I'exemple de diffusion du service IP multicast sur un reseau 
d'acces DAB, le terminal pouvant recevoir potentiellement des services 
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multicast sur plusieurs interfaces reseaux correspondent a des technologies 
differentes. 

1 .a - Le foumisseur de services IP souhaite distribuer son service IP 
jusqu'a des terminaux clients, tel que le terminal T. Pour cela, il fait appel au 
module 4 de mediation, lequel peut etre sous-traite chez un tiers ou integre 
chez le foumisseur de service. Pour cela, le serveur S fournit a la fonction 
"Description de services" du module 4 les elements de description de son 
service IP. 

Les elements fournis sont ceux que I'on trouve dans un fichier de 
description SDP (RFC 327 de I'lETF) standard: a savoir. 

- des informations de niveau applicatif: nom et description litterale du service, 
date de diffusion du service, application necessaire pour decoder le service, 
type de codecs, etc, 

- des donnees de niveau reseau: adresse IP multicast et port UDP necessaire 
pour communiquer avec le service IP multicast. 

En plus des informations de description de service, le foumisseur de 
services fournit, s'il y a lieu, ses preferences en terme de technologie reseau 
d'acces (exemple : si possible DAB, sinon DVB) et d'autres informations 
complementaires afin de completer le cas echeant la demande de ressources 
effectuee en 1.b, par exemple pour un service IP multicast desire sur une 
technologie DAB : le label du service radio auquel le service IP est rattache, la 
bande passante necessaire, la zone geographique ou le service sera opere, 
I'operateur de reseau d'acces souhaite, etc. 

La fonction "Description de services" du systeme 4 stocke la description 
du service dans la base de donnees du systeme. 

1 .b - La fonction «Demande de ressources» du module 4 de mediation 
est informee de I'existence d'un nouveau service IP pour lequel une demande 
de ressources est necessaire. La fonction «Demande de ressources» doit 
alors selectionner la technologie du reseau d'acces. voire I'operateur de 
reseau d'acces. Le choix definitif de la technologie du reseau d'acces peut 
etre fait en fonction des choix du foumisseur de services, des regies comme 
les contrats avec des operateurs d'acces, des informations de charge de 
reseaux d'acces, des facteurs de coGt. 
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II faut rioter qu'un m§me service IP peut §tre transporte simultanement 
stir plusieurs reseaux d'acces de technologie differente, par exemple les 
signalisations DAB et DVB. Dans ce cas, on peut envisager que le module 4 
de mediation etablisse un ordre de priorite des differentes technologies, le 
terminal T se voyant imposer cette priorite. Une autre solution consiste en ce 
que la priorite est definie par le terminal T lui-meme. 

La fonction «Demande de ressources» doit ensuite selectionner les 
informations qui caracteriseront aupres de I'operateur du reseau 1 d'acces la 
demande de ressources: par exemple les adresses IP et port du flux IP. et un 
certain nombre d'elements complementaires comme la bande passante 
desiree. 

2.a - La fonction "Activation des ressources" du systeme 5 recoit la 

demande de ressources. 

2.b - Au cas ou la demande est recevable, par exemple si la bande 
passante necessaire est disponible dans les ressources d'acces DAB, le 
systeme 5 envoie des ordres vers les equipements 3 de transfert afin que le 
service IP puisse etre transporte sur le reseau d'acces. 

2. c - En reponse a la demande de ressources effectuee en 2.a, la 
fonction «Contr6le de ressources* confirme I'attribution des ressources. 

3. a - La fonction "Demande de ressources" du systeme 4 met a jour la 
base de donnees du systeme en ajoutant a la- description du service IP le 
champ "technologie du reseau d'acces" qui definit la technologie du reseau 
d'acces employee, ou des reseaux d'acces employes accompagnes 
eventuellement de la priorite associee, s'il y en a plusieurs reseaux d'acces 
possibles comme indique en 1 .b. Pour le cas d'un reseau d'acces DAB, ce 
champ sera egal par exemple a «DAB». 

3.b - La fonction "Offre de services" du module 4 est informee qu'elle 
doit creer un fichier de decouverte de services associe au service IP. Si la 
decouverte "de services est faite au travers d'un fichier SDP, ce fichier 
contiendra les champs presents dans la base de donnees et regus par la 
fonction decouverte de services (champs d'un fichier SDP standard) et le 
nouveau champ « technologie du reseau d'acces ». Ce champ est place dans 
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une description SDP de niveau media, au cas ou il y aurait plusieurs medias et 
done plusieurs flux IP associes au service IP. 

4. a - Le terminal client T par sa fonction "Decouverte de services" 
decouvre le service IP : 

- soit en envoyant une requete aupres de la fonction "Off re de services" du 
module 4, en telechargeant par exemple le fichier SDP sur un serveur WEB 
mis a jour par la fonction "Offre de services" du module 4, 

- soit par renvoi des informations par la fonction "Offre de services" vers le 
terminal T au travers d'un protocole comme SAP/SDP (RFC 2974). 

4.b - La fonction "Invocation de service", qui peut etre sollicitee au 
moment ou I'utilisateur s6lectionne sur I'interface graphique du terminal T le 
service IP (die sur un icone par exemple), traite le fichier de d6couverte de 
services (fichier SDP par exemple), et done le champ « technologie du r6seau 
d'acces ». 

4.c - La fonction "Invocation de service" du terminal T lance I'application 
en lui fournissant les parametres presents dans le fichier de decouverte de 
services et qui lui sont necessaires. Grace aux parametres de communication 
IP (classiquement adresse(s) IP et port), ['application ouvre la connexion IP. 

4.d - La fonction "Invocation de service" fournit & la fonction "Choix de 
Tinterface du reseau d'acces" I'indication que le service IP d'adresse @ doit 
§tre obtenu au travers d'une interface du terminal T correspondant au champ 
"technologie du reseau d'acces". Pour I'exemple d'un service IP multicast, la 
fonction « Choix de I'interface du reseau d'acces » modifie les parametres de 
configuration r6seau du terminal, de fagon a ce que I'abonnement multicast 
soit fait sur 1'interface appropriee correspondant aux priorites definies par le 
module 4 de mediation ou localement par le terminal T. A noter qu'une autre 
possibility pour les services IP multicast serait que la fonction "Lancement de 
I'application" identifie I'interface a laquelle I'application devra elle-meme 
s'abonner pour consommer le service IP, en fonction du champ « technologie 
du reseau d'acces » fourni par la fonction « Invocation de service ». 

Une fois reaiisee la selection de I'interface du reseau d'acces d'une 
maniere oQ d'une autre, les donnees IP issues du serveur S au travers des 
equipements du reseau 1 d'acces physique sont regues par la carte de 
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reception du terminal T et traitees par I'application desiree (lecteur de video 
par exemple). 

A noter que les cas « multicanal » et << multiinterfaces » peuvent etre 
cumulatifs ; si le reseau d'acces defini par le module de mediation est 
multicanal, I'identifiant de canal sera transmis au terminal lors de la 
d6couverte de services en meme temps que Tidentifiant de voie. La fonction 
«Choix de I'interface du reseau d'accds » relaiera alors vers la bonne 
interface du reseau d'acces multicanal Tidentifiant du canal. 
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REVEND1CATIONS 



1. Procede d'acces, a travers un reseau (1) d'acces multivoies, d'un terminal 
(T) a un service mis £ disposition sur un reseau (2) de communication par un 
fournisseur de services, 

caracterise en ce que ledit procede d'acces comprend les etapes consistant : 

- pour le fournisseur de services, a fournir a un module (4) de m6diation des 
informations concernant au moins des donnees relatives & I'adresse (@, P) 
dudit service dans le reseau (2) de communication, 

- pour le module (4) de mediation, a determiner au moins un identifiant de voie 
a utiliser par le terminal (T) pour acceder audit service, et a associer ledit 
identifiant de voie auxdites informations fournies par le fournisseur (S) de 
services, 

- pour le terminal (T), a recevoir du module (4) de m6diation, lors de ia 
decouverte du service, ledit identifiant de voie associe auxdites informations. 

2. Proced6 selon la revendication 1, caract6ris6 en ce que, le r6seau d'acces 
multivoies etant un reseau d'acces multicanal, ledit identifiant de voie 
comprend, au moins, un identifiant de localisation du canal 3 utiliser par le 
terminal dans ledit reseau d'acces multicanal. 

3. Procede selon la revendication 2, caracteris6 en ce que le module (4) de 
mediation determine le reseau (1) d'acc6s multicanal & utiliser, et regoit dudit 
reseau d'acces ledit identifiant de localisation. 

4. Procede selon Tune des revendications 2 ou 3, caracterise en ce que ledit 
reseau d'acces multicanal est un reseau utilisant la signalisation DVB. 

5. Procede selon Tune des revendications 2 ou 3, caract6ris6 en ce que ledit 
identifiant de canal comprend en outre un identifiant de la technologie dudit 
reseau d'acces multicanal. 

6. Procede selon la revendication 5, caract§ris6 en ce que ledit reseau 
d'acces multicanal est un r§seau utilisant la signalisation DAB. 

7. Proc6d6 selon la revendication 6, caracterise en ce que ledit identifiant de 
canal est constitu6 par le couple Sid, SCIds. 
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8. Procede selon Tune quelconque des revendications 2 a 7, caracterise en ce 
que ledit terminal (T) s'accorde sur le canal correspondant audit identifiant de 
voie. 

9. Procede selon la revendication 1, caracterise en ce que, le reseau d'acces 
multivoies etant constitue par une pluralite d'interfaces du terminal & des 
reseaux d'acces, ledit identifiant de voie est un identifiant d'au moins une 
technologie a utiliser. 

10. Procede selon la revendication 9, caracteris6 en ce que le module (4) de 
mediation determine la technologie d'acces a utiliser. 

11. Procede selon la revendication 10, caracterise en ce que, en cas de 
pluralite de technologies aptes & etre utilisees, le module (4) de mediation 
definit une priorite desdites technologies. 

12. Procede selon la revendication 10, caracterise en ce que, en cas de 
pluralite de technologies aptes d §tre utilis6es, le terminal (T) d6finit une 
priorite desdites technologies. 

13. Procede selon Tune quelconque des revendications 10 a 12, caracterise 
en ce que, en cas de pluralite d'interfaces pour une technologie donnee, le 
terminal (T) determine I'interface a utiliser. 

14. Procede selon Tune quelconque des revendications 9 a 13, caracterise en 
ce que ledit terminal (T) se connecte sur [Interface reseau correspondant 
audit identifiant de voie. 

15. Procede selon I'une quelconque des revendications 1 a 14, caracterise en 
ce que les informations re$ues par le module (4) de mediation provenant du 
fournisseur de service concernent egalement des donnees relatives au 
service. 

16. Systeme d'acces, a travers un reseau (1) d'acces multivoies, d'un terminal 
(T) a un service mis a disposition sur un reseau (2) de communication par un 
fournisseur de services, 

caracteris§ en ce que ledit systeme d'acces comprend un module (4) de 
mediation apte : 

- a recevoir du fournisseur de services des informations concernant au moins 
des donnees relatives a I'adresse (@, P) dudit service dans le r6seau (2) de 
communication, 
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- a determiner au moins un identifiant de voie a utiliser par le terminal (T) pour 
acc6der audit service, et a associer ledit identifiant de voie auxdites 
informations fournies par le fournisseur (S) de services, 

- a fournir au le terminal (T), lors de la decouverte du service, ledit identifiant 
de voie associe auxdites informations. 

17. Systeme d'acces selon la revendication 16, caracterise en ce que, le 
reseau d'acces etant un r6seau d'acces multicanal, le module (4) de mediation 
est apte a determiner le reseau (1) d'acces multicanal a utiliser, et re<?oit dudit 
reseau d'acces un identifiant de localisation du canal a utiliser par le terminal 

CO- 

18. Systeme d'acces selon la revendication 16, caracterise en ce que, le 
reseau d'acces multivoies etant constitue par une pluralite d'interfaces du 
terminal k des reseaux d'accds, le module (4) de mediation est apte a 
determiner la technologie d'acces £ utiliser. 

19. Systeme d'acces selon I'une quelconque des revendications 16 a 18, 
caracterise en ce que ledit terminal (T) est apte a s'accorder sur le canal 
correspondant audit identifiant de voie. 

20. Systeme d'acces selon Tune quelconque des revendications 16 a 18, 
caracterise en ce que ledit terminal (T) est apte a se connecter sur Interface 
reseau correspondant audit identifiant de voie. 

21. Module de mediation pour un systeme d'acces, a travers un reseau (1) 
d'acces multivoies, d'un terminal (T) a un service mis a disposition sur un 
reseau (2) de communication par un fournisseur de services, 

caracterise en ce que ledit module (4) de mediation est apte : 

- a recevoir du fournisseur de services des informations concernant au moins 
des donnees relatives a I'adresse (@, P) dudit service dans le reseau (2) de 
communication, 

- a determiner au moins un identifiant de voie a utiliser par le terminal (T) pour 
acceder audit service, et a associer ledit identifiant de voie auxdites 
informations fournies par le fournisseur (S) de services, 

- a fournir au le terminal (T), lors de la decouverte du service, ledit identifiant 
de voie associe auxdites informations. 
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22. Module de mediation selon la revendication 21, caract6ris6 en ce que, le 
reseau d'acces etant un reseau d'acces multicanal, le module (4) de mediation 
est apte a determiner le reseau (1) d'acces multicanal a utiliser, et regoit dudit 
reseau d'acces un identifiant de localisation du canal a utiliser par le terminal 

(T). 

23. Module de mediation selon la revendication 21, caracterise en ce que, le 
reseau d'acces multivoies etant constitue par une pluralite d'interfaces du 
terminal a des reseaux d'acces, le module (4) de mediation est apte a 
determiner la technologie d'acces a utiliser. 
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